Hi, thank you for your interest and resolving this issue and for putting together this PR! While I see from your videos it stops the workspace movement, I think the original call to setResizesEnabled() is still necessary, because it pairs with the corresponding call in startDrag() to reenable workspace resizing after startDrag() disables it for the duration of the drag. In cases where the drag does not result in deletion, resizing would never be reenabled with this change. If you're interested in investigating further, I'd investigate the calls to snapToGrid() and queueRender(); my suspicion is there may be a race condition with block deletion and the things (like snapping and rerendering) we'd do at the end of a normal non-deletion drag which are unnecessary if the block is being deleted but desirable (and could potentially result in adjusting the workspace bounds) in the case where a block is just being moved.

Hi, thank you for your interest and resolving this issue and for putting together this PR! While I see from your videos it stops the workspace movement, I think the original call to setResizesEnabled() is still necessary, because it pairs with the corresponding call in startDrag() to reenable workspace resizing after startDrag() disables it for the duration of the drag. In cases where the drag does not result in deletion, resizing would never be reenabled with this change. If you're interested in investigating further, I'd investigate the calls to snapToGrid() and queueRender(); my suspicion is there may be a race condition with block deletion and the things (like snapping and rerendering) we'd do at the end of a normal non-deletion drag which are unnecessary if the block is being deleted but desirable (and could potentially result in adjusting the workspace bounds) in the case where a block is just being moved.

Hello! I have been debugging this issue and it indeed looks like a race condition. The reason for this is because this.block.queueRender() returns a Promise, which is async.

Marking endDrag method from block_drag_strategy as async and then inserting await to queueRender (as await this.block.queueRender()) does fixes the issue however. Should I choose this approach or attempt other fix?

After the latest changes, here is how it looks like:
latest.webm

Ah, this looks pretty in line with what I suspected, thank you for digging into it! Would you mind adjusting it to use renderManagement.finishQueuedRenders().then(() => { // Everything after the if, from snapToGrid() to setGroup(false) }) to avoid making the whole function async?

@gonfunko done. Now the method is no longer async and we have a reusable method that can be executed both sync/async.

Looks good! Thanks for taking care of this and working through the back and forth, I and the rest of the Blockly team appreciate it!